Retention: perform the deletions the privacy policy promises - #69

The policy went live on rootsystem.com committing to three deletions and
nothing performed any of them. This is the Worker that does.

A separate Worker rather than a cron on the forensics site. This one
deletes data, and a fault in it must not be able to take down a request
path; it also has no fetch handler at all, so the cron is the only way
in and there is nothing to authenticate.

The three tasks match the policy clause for clause. The 90-day intake
purge blanks `matter_summary` and never deletes the row -- the conflict
record is in the same row and is kept for as long as the practice
operates, so a DELETE would quietly destroy what the conflict screen runs
against. Spam-judged intake rows are the one case that is deleted
outright: a submission judged automated carries no conflict record worth
keeping. Contact enquiries go at twelve months.

Cutoffs are evaluated by SQLite's own `datetime('now', ...)` rather than a
Date built in the Worker, so the comparison uses the same clock that
wrote `created_at` and no timezone question arises. The intake purge is
guarded on `matter_summary <> ''` so that already-purged rows are not
recounted as affected on every subsequent run, which would make the log
meaningless.

Migration 0004 adds `retention_runs`. Every task writes a row even when
it changed nothing, because a zero and a missing row are different facts:
one proves the job ran and found nothing due, the other proves it did not
run. It records counts only -- logging which rows lost a description, let
alone what they said, would rebuild a shadow of the thing being deleted.

Tasks are independent. One failing does not skip the others, since a
transient error on one statement is no reason to defer a deletion that is
due today.

Verified against a seeded local database: a 100-day-old matter had its
description blanked and its row kept, a 10-day-old one was untouched, a
400-day-old spam row and a 400-day-old contact enquiry were deleted, and
10-day-old equivalents survived. A second run recorded zeros for all
three tasks, which is the idempotency check.

CI deploys it from primary only; a pull request gets `--dry-run`, because
a version upload of a cron-only Worker produces nothing to look at while
a dry run still catches config and bundling errors.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J53xszP5CdZLXfhRJWsSyv